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Abstract.  There  is  an  increasing  need,  within  organizations  such  as  the 
Department  of  Defense  and  NASA,  for  building  distributed  applications 
that  are  rapidly  re-configurable  and  survivable  in  the  face  of  attacks  and 
changing  mission  needs.  Existing  methods  and  tools  are  inadequate  to 
deal  with  the  multitude  of  challenges  posed  by  application  development 
for  systems  that  may  be  distributed  over  multiple  physical  nodes  sepa¬ 
rated  by  vast  geographical  distances.  The  problem  is  exacerbated  in  a 
hostile  and  unforgiving  environment  such  as  space  where,  in  addition, 
systems  are  vulnerable  to  failures.  It  is  widely  believed  that  intelligent 
software  agents  are  central  to  the  development  of  agile,  efficient,  and  ro¬ 
bust  distributed  applications.  This  paper  presents  details  of  agent-based 
middleware  that  could  be  the  basis  for  developing  such  applications.  We 
pay  particular  attention  to  the  correctness,  survivability,  and  efficiency 
of  the  underlying  middleware  architecture,  and  develop  a  middleware 
definition  language  that  permits  applications  to  use  this  infrastructure 
in  a  scalable  and  seamless  manner. 


1  Introduction 

There  is  an  increasing  need,  both  within  Government  and  Industry,  for  methods' 
and  tools  to  develop  highly  distributed  and  robust  computer-based  systems. 
Moreover,  software-intensive  systems  in  safety-  and  mission-critical  areas,  such 
as  software  for  manned  and  unmanned  space  missions  within  NASA,  or  the 
Network-Centric  Warfare  [6],  Total  Ship  Computing,  and  FORCEnet  initiatives 
of  the  Department  of  Defense  (DoD),  are  of  exceedingly  high  complexity  and 
must  in  addition  be  dependable,  robust,  and  adaptive.  A  recent  Department 
of  Defense  (DoD)  report  to  Congress  [10]  identifies  the  lack  of  secure,  robust 
connectivity  and  interoperability  as  one  of  the  major  impediments  to  progress 
in  Network  Centric  Warfare. 
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2  Why  Software  Agents? 


It  is  widely  acknowledged  that  intelligent  software  agents  are  central  to  the 
development  of  the  capabilities  required  to  write  robust,  reconfigurable,  and 
survivable  distributed  applications.  This  is  because  agents  are  an  efficient,  ef¬ 
fective,  and  survivable  means  of  information  distribution  and  access.  Agents  are 
efficient  because  only  relevant  information  needs  to  be  passed  along.  Agents  are 
effective  because  they  allow  local  control  over  updates  and  the  dissemination  of 
data.  Agents  are  survivable  because  their  control  is  distributed.  This  new  tech¬ 
nology,  which  includes  both  autonomous  and  mobile  agents,  addresses  many  of 
the  challenges  posed  by  distribution  of  applications  and  is  capable  of  achieving 
the  desired  quality  of  service  especially  over  unreliable,  low-bandwidth  commu¬ 
nication  links.  However,  agents  technology  carries  with  it  associated  security 
vulnerabilities.  Distributed  computing  in  general  carries  with  it  risks  such  as 
denial  of  service,  Trojan  horses,  information  leaks,  and  malicious  code.  Agents 
technology,  by  introducing  autonomy  and  code  mobility,  may  exacerbate  some 
of  these  problems.  In  particular,  a  malicious  agent  could  do  serious  damage  to 
an  unprotected  host,  and  malicious  hosts  could  damage  agents  or  corrupt  their 
data.  Such  threats  become  very  real  in  a  distributed  computing  environment,  in 
which  a  malicious  intruder  may  be  actively  trying  to  disrupt  communications. 

The  Secure  Agents  Middleware  (SAM)  is  being  designed  to  provide  the  re¬ 
quired  degree  of  trust  in  addition  to  meeting  a  set  of  achievable  security  re¬ 
quirements.  Such  an  infrastructure  is  central  to  the  successful  deployment  and 
transfer  of  agents  technology  to  industry  because  security  is  a  necessary  pre¬ 
requisite  for  distributed  computing.  To  make  agent-based  systems  economically 
viable,  it  is  imperative  that  their  development,  upgrade,  integration,  testing, 
certification,  and  delivery  be  rapid  and  cost-effective.  However,  immense  and 
profound  challenges  of  software  trustworthiness  remain.  Methods  and  tools  for 
software  development  that  are  available  commercially  are  not  sufficient  to  meet 
the  challenges  posed  by  the  distribution  of  processing  functions,  real-time  and 
non-real-time  integration,  multi-level  security,  and  issues  characteristic  of  COTS 
products,  such  as  malicious  code,  viruses,  worms,  and  Trojan  horses. 

3  Requirements  for  Secure  Mobile  Agents 

Security  is  a  fundamental  concern  in  SAM.  By  building  security  from  the 
ground  up  into  SAM,  we  gain  efficiency  by  identifying  and  dealing  with  potential 
bottlenecks  early,  i.e.,  at  the  design  state.  SAM  provides  an  efficient  architecture 
and  ensures  security  by  eliminating  unnecessary  and/or  insecure  communication 
among  agents  and  hosts.  Our  classification  of  requirements  for  secure  mobile 
agents  is  from  FGS961.  For  the  initial  release  of  SAM  we  shall  assume  a  degree 
of  trust  among  the  participants.  This  is  reasonable  in  a  large  organization  such 
as  the  DoD  or  NASA  where  it  may  be  assumed  that  other  policing  methods  and 

1  “Security  for  Mobile  Agents:  Issues  and  Requirements,”  William  N.  Farmer,  Joshua 
D.  Guttman,  and  Vipin  Swarup,  The  MITRE  Corporation,  Bedford,  MA. 


techniques  for  intrusion  detection  and  tolerance  will  identify  and  sift  out  casual 
intruders  and  eavesdroppers  or  programs  carrying  malicious  payloads.  However, 
we  plan  to  address  this  very  important  research  issue  in  greater  detail  in  the 
later  stages  of  this  effort. 

This  project  addresses  the  following  security  requirements: 

—  The  author  and  sender  of  an  agent  are  authenticated. 

—  The  correctness  of  an  agent’s  code  is  checked. 

—  Privacy  is  maintained  during  transmission  by  encrypting  agent  data. 

—  Hosts  protect  themselves  against  malicious  agents  by  first  authenticating  an 
agent  and  checking  that  its  proposed  activities  are  authorized. 

—  Host  safety  is  ensured  by  created  agents  in  a  language  SOL  [2]  that  promotes 
the  development  of  safe  programs. 

—  Senders  have  control  over  their  agents,  e.g.,  they  may  restrict  or  increase  an 
agent’s  authorization  in  particular  situations. 

—  By  equipping  each  agent  with  a  state  appraisal  function,  hosts  can  ensure 
that  an  agent  is  always  in  a  safe  state. 

—  Senders  have  control  over  which  hosts  have  the  authority  to  execute  an  agent. 

4  A  Brief  Introduction  to  SOL 

Agents  are  created  in  a  special  purpose  synchronous  programming  language 
called  Secure  Operations  Language  (SOL)  [2,4, 1].  A  SOL  application  comprises 
a  set  of  agent  modules,  each  of  which  runs  on  a  given  host.  The  host  executes 
an  agent  module  in  compliance  with  a  set  of  locally  enforced  security  policies. 
A  SOL  multi-agent  system  may  run  on  one  or  more  hosts,  spanning  multiple 
networks  and  multiple  administrative  domains. 

A  module  is  the  unit  of  specification  in  SOL  and  comprises  variable  decla¬ 
rations,  assumptions  and  guarantees,  and  definitions.  The  assumptions  section 
typically  includes  assumptions  about  the  environment  of  the  agent.  Execution 
aborts  when  any  of  these  assumptions  are  violated  by  the  environment.  The 
required  safety  properties  of  an  agent  are  specified  in  the  guarantees  section. 
The  definitions  section  specifies  updates  to  internal  and  controlled  variables. 

A  variable  definition  is  either  a  one-state  or  a  two-state  definition.  A  one- 
state  definition,  of  the  form  x  =  expr  (where  expr  is  an  expression),  defines  the 
value  of  variable  x  in  terms  of  the  values  of  other  variables  in  the  same  state.  A 
two-state  variable  definition,  of  the  form  x  =  initially  init  then  expr  (where 
expr  is  a  two-state  expression) ,  requires  the  initial  value  of  x  to  equal  expression 
init ;  the  value  of  x  in  each  subsequent  state  is  determined  in  terms  of  the  values 
of  variables  in  that  state  as  well  as  the  previous  state  (specified  using  operator 
PREV).  A  conditional  expression ,  consisting  of  a  sequence  of  branches  “[]  guard 
— >  expression”,  is  introduced  by  the  keyword  “if”  and  enclosed  in  braces  ("{" 
and  "}").  A  guard  is  a  boolean  expression.  The  semantics  of  the  conditional 
expression  if  {  \\gi  — »■  exprj  []g2  — t  expr2  ...  }  is  defined  along  the  lines  of 
Dijkstra’s  guarded  commands  [7]  -  in  a  given  state,  its  value  is  equivalent  to 
expression  expr,:  whose  associated  guard  <?,;  is  true.  If  more  than  one  guard  is  true, 


deterministic  reactive  module  SecureRead  { 


interfaces 

string  f ile_read(string  filename,  int  position,  int  size); 
void  send(string  address,  string  data); 

internal  variables 

{no_reads,  read_perf ormed}  status; 

definitions 

status  =  initially  no_reads  then 
case  PREV(status)  { 

[]  no_reads  -> 
if  { 

[]  @send  ->  PREV(status) 

[]  <§file_read  ->  read_performed 

} 

[]  read_performed  -> 
if  { 

[]  @file_read  ->  read_performed 
//  Osend  illegal! 

> 

};  //  end  case 
}  //  end  module  SecureRead 

Fig.  1.  A  SOL  agent  module  that  implements  safe  access  to  local  files. 


the  expression  is  nondeterministic.  It  is  an  error  if  none  of  the  guards  evaluates  to 
true,  and  execution  aborts.  The  case  expression  case  expr  {  []iq  — >  exprx  []uo  — > 
expr2  ...  }  is  equivalent  to  the  conditional  expression  if  {  [](expr  ==  rq)  — t 
exprj  [](expr  ==  v 2)  — t  expr2  ...  }.  The  conditional  expression  and  the  case 
expression  may  optionally  have  an  otherwise  clause  with  the  obvious  meaning. 

5  Enforcement  Automata 

In  this  section,  we  shall  examine  how  enforceable  safety  and  security  policies  [11] 
are  expressed  in  SOL  as  enforcement  automata  (also  known  as  security  agents 
[3]).  The  enforcement  mechanism  of  SOL  works  by  terminating  all  executions  of 
a  program  for  which  the  policy  being  enforced  no  longer  holds.  For  reasons  of 
readability  and  maintainability,  we  prefer  to  use  explicit  automata  for  enforcing 
safety  properties  and  security  policies,  although  any  language  that  allows  ref¬ 
erences  to  previous  values  of  variables  may  suffice.  Unlike  assertions,  where  no 
additional  state  is  maintained,  SOL  enforcement  automata  may  include  addi¬ 
tional  variables  that  are  updated  during  the  transitions  of  the  automata. 

5.1  Security  Automata 

We  use  the  example  from  [11]  to  illustrate  how  we  may  implement  a  security 
policy  that  allows  a  software  agent  to  send  data  to  remote  hosts  (using  method 


send)  as  well  as  read  local  files  (using  method  f  ile_read).  However,  invocations 
of  send  subsequent  to  f  ile_read  are  disallowed.  It  is  difficult,  if  not  impossible, 
to  configure  current  systems  to  implement  such  a  policy.  For  example,  it  cannot 
be  implemented  in  the  “sandbox”  model  of  Java  [8]  in  which  one  may  either 
always  or  never  allow  access  to  a  system  resource.  As  shown  in  Figure  1,  this 
policy  is  easily  implemented  in  SOL. 

6  Formal  Semantics  of  SOL 

State  Machines  A  SOL  agent  module  describes  a  state  machine  [2],  A  state  ma¬ 
chine  A1  is  a  quadruple  ( V ,  S,0,p ),  where  V  =  {vi,vz, . . . ,  vn}  is  a  finite  set  of 
state  variables ;  S  is  a  nonempty  set  of  states  where  each  state  s  £  S  maps  each 
v  £  V  to  its  range  of  legal  values;  0  :  S  — >  boolean  is  a  predicate  characteriz¬ 
ing  the  set  of  initial  states ;  p  :  S  x  S  — >  boolean  is  a  predicate  characterizing 
the  transition  relation.  We  write  0  as  a  logical  formula  involving  the  names  of 
variables  in  V.  Predicate  p  relates  the  values  of  the  state  variables  in  a  previous 
state  s  £  S  to  their  values  in  the  current  state  s'  £  S.  We  write  p  as  a  logical 
formula  involving  the  values  of  state  variables  in  the  previous  state  (specified 
using  operator  PREV)  and  in  the  current  state. 

SOL  Predicates  Given  a  state  machine  A  =  (V,S,0,p)  we  classify  a  predicate 
p  :  S  — >  boolean  as  a  one-state  predicate  of  A  and  a  predicate  q  :  S  x  S  — >  boolean 
as  a  two-state  predicate  of  A. 

More  generally,  SOL  predicate  refers  to  either  a  one-state  or  two-state  predi¬ 
cate,  and  SOL  expression  refers  to  logical  formulae  or  terms  containing  references 
to  current  or  previous  values  of  state  variables  in  V. 

Reachability  Given  a  state  machine  A  =  (A,  S,  0,p),  a  state  s  £  S  is  reachable 
(denoted  Reachable s(s))  if 

(i)  0(s)  or 

(ii)  3s'  £  S  :  Reachable e (s')  and  p(s',s ) 

Invariants  A  one-state  predicate  p  is  a  state  invariant  of  A  if  and  only  if 

Vs  :  Reachables(s)  =>-  p(s) 

A  two-state  predicate  q  is  a  transition  invariant  of  A  if  and  only  if 

Vs,  s'  :  (Reachables(s)  A  p(s,s'))  =>  g(s,s') 

More  generally,  a  SOL  predicate  x  is  an  invariant  of  A  if  x  is  a  state  invariant 
or  transition  invariant  of  A. 

Verification  For  a  SOL  agent  module  describing  a  state  machine  A,  and  a  set 
of  SOL  predicates  X  =  xi,x%, . . .,  verification  is  the  process  of  establishing  that 
each  SOL  predicate  x*  £  -Y  is  an  invariant  of  A. 


7  SOL  Agent  Modules 

A  SOL  agent  module  describes  both  an  agent’s  environment,  which  is  usually 
nondeterministic,  and  the  required  agent  behavior,  which  is  usually  determin¬ 
istic  [5,9].  A  SOL  agent  module  describes  the  required  relation  between  moni¬ 
tored  variables ,  environmental  quantities  that  the  agent  monitors,  and  controlled 
variables ,  environmental  quantities  that  the  agent  controls.  Additional  internal 
variables  are  often  introduced  to  make  the  description  of  the  agent  concise.  In 
this  paper,  we  only  distinguish  between  monitored  variables,  i.e.,  variables  whose 
values  are  specified  by  the  environment,  and  dependent  variables ,  i.e.,  variables 
whose  values  are  dependent  on  the  values  of  monitored  variables.  Dependent 
variables  include  all  the  controlled  variables  and  internal  variables  of  an  agent 
module.  In  the  sequel,  we  assume  that  variables  v\ ,  Vi , . . . ,  vi  are  an  agent’s  mon¬ 
itored  variables,  and  that  variables  r/ .  i  .v.\  ...2. . . .  ,vn  are  the  agent’s  dependent 
variables.  The  notation  NC(v\  ,V2,  ■  ■  ■ ,  Vk)  is  used  as  an  abbreviation  for  the 
SOL  predicate  (vi  =  PREV(v  1))  A  (uo  =  PREV(v o))  A  ...  A  (vk  =  PREV  {vi)). 

Components  of  the  state  machine  E  =  (V,  S,  0,  p)  are  specified  in  the  section 
definitions  of  a  SOL  agent  module.  The  initial  predicate  0  is  specified  in  terms 
of  the  initial  values  for  each  variable  in  V,  i.e.,  as  predicates  8vi,9V2, . . .  ,6vn, 
so  that  0  =  8vi  A  0V2  A  ...  A  8vn.  The  transition  relation  p  is  specified  as  a  set 
of  assignments,  one  for  each  dependent  variable  of  A,  i.e.,  as  SOL  predicates 
Pvi+i,  Pvi+2)  ■  ■  • ,  Pvn  y  each  of  which  is  of  the  form: 

{ei  if  91 
e-2  if  g-2 

where  1  <  i  <  n,  and  ei,eo,...  are  SOL  expressions,  and  gi,g2,  ■  ■  ■  are  SOL 
predicates.  To  avoid  circular  definitions,  we  impose  an  additional  restriction  on 
the  occurrences  of  state  variables  in  these  expressions  as  below: 

Define  dependency  relations  Dnew,  D0ia,  and  D  on  V  x  V  as  follows: 

For  variables  ig  and  vj,  the  pair  (vj,vj)  G  Dnew  iff  vj  occurs  outside  a 
PREV ()  clause  in  the  SOL  expression  defining  vp,  the  pair  i'j  )  £  D0id 
iff  PREV { Vj )  occurs  in  the  SOL  expression  defining  vp  and  D  =  Dnew  U 
D0id-  We  require  Dfew,  the  transitive  closure  of  the  Dnew  relation,  to 
define  a  partial  order. 

7.1  Composition  of  SOL  Agent  Modules 

Consider  two  SOL  agent  modules  describing  the  state  machines  E\  =  (Vi ,  Si ,  @1 ,  p\ ) 
and  Ah  =  (V2,  S%,  @2,  Pi)-  We  define  the  coinposition  of  the  two  SOL  agents 
E  =  (V,S,0,p)  as  E  =  A'lllAo  where 

V  =  Cl  U  Do 
0  =  0\  A  02 

p  =  Pi  A  p2 

Each  s  £  S  maps  each  v  £  V  to  its  range  of  legal  values 


provided  that  there  is  no  circularity  in  the  occurrences  of  variables  in  p.  Also  in 
practice,  it  is  the  case  that  p\  and  po  define  disjoint  sets  of  state  variables. 


8  Conclusions 

We  plan  to  continue  the  development  of  design  and  analysis  tools  for  SOL  agents, 
and  verification  tools  such  as  automatic  invariant  generators  and  checkers,  the¬ 
orem  provers,  and  model  checkers.  We  currently  have  a  compiler  for  SOL  which 
generates  Java  code  suitable  for  execution  on  multiple  hosts.  Planned  extensions 
to  the  compiler  include  support  for  fine-grained  security  and  problems  associated 
with  survivability  such  as  fault-tolerance,  load  balancing,  and  self-stabilization. 

The  goal  of  the  NRL  secure  agents  project  is  to  develop  enabling  technology 
that  will  provide  the  necessary  security  infrastructure  to  deploy  and  protect 
time-  and  mission-critical  applications  on  a  distributed  computing  platform.  Our 
intention  is  to  create  a  robust  and  survivable  information  grid  that  will  be  capable 
of  resisting  threats  and  surviving  attacks.  One  of  the  criteria  on  which  this 
technology  will  be  judged  is  that  critical  information  is  conveyed  to  principals  in 
a  manner  that  is  secure,  safe,  timely,  and  reliable.  No  malicious  agencies  or  other 
threats  should  be  able  to  compromise  the  integrity  or  timeliness  of  delivery  of 
this  information. 
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